home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: MegaDisc / MegaDisc 06 (1988)(MegaDisc Digital Publishing)(AU)[m][WB].zip / MegaDisc 06 (1988)(MegaDisc Digital Publishing)(AU)[m][WB].adf / ARTICLES / CommProtocols < prev    next >
Text File  |  1988-03-28  |  6KB  |  129 lines
  1.  
  2.             File Transfer Protocols.
  3.             ************************
  4.  
  5.     ED. NOTE: This is a good coverage of the various Communications
  6.     protocols available, by the sysop of Sydney's best bbs, where you'll
  7.     find lots of files, and a Megadisc section for uploading and
  8.     downloading Megadisc files. Tel: (02) 5216338.
  9.  
  10. A file transfer Protocol is like a language used to agree on how a file
  11. should be transferred. The nice part about transfer protocols is that they
  12. work regardless of the types of computers involved. File transfer protocols
  13. send data in what is know as blocks. That is, the file is sent to the other
  14. system one block at a time. Each block is checked for integrity and if an
  15. error is detected, the receiving system requests the host system to resend
  16. the block.
  17.  
  18. As long as both systems agree on the SAME file transfer protocol, most
  19. transfers are error free and extremely simple to initiate.
  20.  
  21. The following list are the most common file transfer protocols and each one
  22. will be discussed in detail. The protocols are listed in rough order of
  23. their accuracy (error detection) and transfer speed.
  24.  
  25.                 Ascii Text
  26.                 Kermit
  27.                 X-Modem
  28.                 X-Modem-CRC
  29.                 Y-Modem-Batch
  30.                 Y-Modem
  31.                 Z-Modem
  32.  
  33. If your telecommunications program supports Y-Modem or Z-Modem then use one
  34. of these as they are both the most reliable and fastest.
  35.  
  36. With the exception of Ascii Text, all other protocols use some form of error
  37. checking. Error-checking is a feature whereby the file transfer protocol
  38. tries to monitor the transfer and compensate for poor quality or surplus line
  39. noise which can scramble data. When an error is detected, the receiving
  40. system prompts the host to resend that block.
  41.  
  42.             Protocols In Profile
  43.             ********************
  44.  
  45. ASCII TEXT: This is a very basic file transfer Protocol. When a binary file
  46. is sent, it is converted into it's Hexadecimal values and displayed on the
  47. screen. This is the only protocol where you acually see the data being
  48. transferred. No error checking is supported! Before you use this protocol
  49. to download a file, open a capture buffer and make sure it is closed, That
  50. is, the capture buffer is available to store data to disk, but the actual
  51. buffer is closed to prevent unwanted data from entering the buffer. When you
  52. download a file using this protocol the host usually sends a decimal 18
  53. command which most telecommunications programs recognise as a signal to open
  54. the capture buffer to store the HEX display, when the transfer is complete
  55. the host sends a decimal 20 which closes the capture buffer. This way,
  56. unwanted data is prevented from entering the Hex coded download file. The
  57. receiving telecommunications program should have a facility to convert the
  58. HEX code back to an executeable program. If the file is a text file then the
  59. buffer is opened as above but not converted to HEX.
  60.  
  61.  
  62. KERMIT: This has been the standard protocol used by Mainframe systems for
  63. many years. If you use this protocol, setting your stop bits to 1, word
  64. length to 7 and Even Parity will increase the transfer time two-fold for
  65. binary files, you are advised to use a stop bit of 1, word length of 8 and No
  66. Parity.
  67. Kermit automatically sends the filename along with the filesize. The
  68. receiving system need only select file receive and the host and Kermit
  69. handle the rest.
  70.  
  71. X-Modem: This is the protocol originally written by Ward Christensen and in
  72. use by almost every type of computer.
  73. It is the same as X-Modem-CRC, only it uses Checksum error correction instead
  74. of CRC, which is not as reliable.
  75.  
  76. X-Modem-CRC: This has long been a standard with its outstanding error
  77. detection. It's biggest drawback is it transfers data in 128 byte blocks. as
  78. with kermit 8N1 is used over 7E1 for time saving.
  79.  
  80. Y-Modem Batch: This is the same as Y-Modem, only the filesname is not entered
  81. at the receiving end of the system. Y-Modem Batch sends the filoename along
  82. with the filesize. The receiving system only selects file receive. When
  83. uploading using Y-Modem Batch you are usually not prompted for a filename as
  84. this is sent by the protocol.
  85.  
  86. Y-Modem: This is basically X-Modem-CRC with 1024 byte blocks. The advantage
  87. is, more data sent per block. thus less blocks to error check which is
  88. time consuming. The only problem is when line quality is poor, 128 byte
  89. blocks take less time to resend.
  90.  
  91. Z-MODEM: Currently this is the fastest file transfer protocol in the public
  92. domain. A file is normally sent in 1024 byte blocks. This value changes based
  93. on system performance and is automatically handled by Z-Modem. The reason
  94. for Z-Modem's outstanding performance is the way it detects errors. With
  95. the exception of Ascii Text, the protocols listed send one block of
  96. information at a time and wait for the remote system to receive it,
  97. acknowledges the block and then sends the command to continue with the next
  98. block. Z-Modem uses continuous data streaming, it doesn't wait for an OK from
  99. the remote system before sending the next block. In effect Z-Modem ignores
  100. the stop signals until an error is detected, the receiving system sends a
  101. request to the host to re-send the data from where the error occurred. While
  102. several kilobytes of data may belost due to the delay in receiving the error
  103. message, the overall transfer rate is far superior and outweighs an
  104. occassional bad block.
  105. This Protocol proves useful when calling through a packet network. Packet
  106. networks normally experience long delays using the traditional file transfer
  107. protocols, since it takes several seconds before an acknowledgement is
  108. received from the remote system. In the same time Z-Modem can send two or
  109. more blocks of data.
  110.  
  111. Always make sure you initiate your file transfer protocol from the host end
  112. FIRST, and then complete  the transfer sequence at the receiving end. Your
  113. telecommunications package should provide the necessary information to
  114. transfer files.
  115.  
  116. NB:
  117.  X-Modem, Y-modem and Y-Modem-Batch will pad a file with extraneous
  118. characters to make the file length a multiple of either 128 or 1024 bytes,
  119. this usually makes the file unexecutable. A public domain file called FIXOBJ
  120. is used to rid downloaded files of the extra padding and retsore them to
  121. executable form.
  122. Arc-ed files should not need this procedure to be performed.
  123.  
  124. Hope this helps
  125. Ross Kellaway.
  126.                 ********
  127.  
  128.  
  129.